Many foreign countries adopt a GSM® (Global System for Mobile communications) system as a mobile phone system. In the GSM® system, a SIM (Subscriber Identity Module) card as one kind of IC cards is indispensable in a mobile phone.
In Japan, a mobile phone system, which adopts a 3GPP (3rd Generation Partnership Project) standard in place of the GSM®, has been launched. In the 3GPP standard as well, a USIM (Universal Subscriber Identity Module) card as an IC card similar to the SIM card is indispensable.
The SIM and USIM cards used in the GSM® and 3GPP are inserted in mobile phone terminals. The SIM and USIM cards record key information, encryption algorithms, and various network parameters required to establish connections to communication networks of telecommunications carriers. Each mobile phone terminal sends these pieces of information to an OTA (Over The Air) server, authentication/management server, and the like of the telecommunications carrier, and executes authentication with these servers. When the authentication result is correct, the mobile phone terminal can receive communication services of that telecommunications carrier.
In standards (ETSI TS 102 223, ETSI TS 102 241), specifications called CAT (Card Application Toolkit) are specified. The CAT is installed in a card (to be referred to as a UIM hereinafter) represented by the SIM, USIM, and UIM cards of IC cards, which are required to identify subscriber information of, for example, mobile phones. As one of the CAT specifications, a function called a Proactive command, which is required to send various operation requests and information from the UIM to a mobile phone (to be referred to as an ME hereinafter) or network server, is specified.
According to the standards, when an Applet called a ToolKit Applet or embedded software is executed in the UIM, a Proactive command send request is often generated in the UIM. At this time, the UIM sends a Proactive command as response data to a Fetch command sent from the ME. However, the UIM cannot output the Proactive command before the ME sends the Fetch command.
On the other hand, in the HIM, another Proactive command send request may be generated by an operation of the Applet independently of this state. For this reason, when a state in which the UIM does not receive any Fetch command (the ME does not send any Fetch command) is continued, unsent Proactive commands are accumulated in the UIM.
When the ME supplies a reset signal to the UIM, information of unsent Proactive commands is also reset. Hence, a Proactive command to be sent cannot often be sent.
Therefore, there is a need for preventing data to be sent to the ME, which is generated by a specific command in the UIM, from being accumulated while being kept unsent, or preventing data to be sent to the ME, which is generated by a specific command, from being erased involuntarily.